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© Bridge system for connecting networks. 



© A large number of local area networks are each 
connected to a backbone network through a network 
.interface module <NIM). The NIM transmits mes- 
sages from one local area network to another local 
area network across the backbone network by envel- 
oping the local area network message inside the 
data field of a backbone network message. Each of 
the NIM constructs a table of addresses. The back- 
bone network messages are each addressed to the 
particular destination NIM. The destination NIM re- 
ceives the backbone network message and de-en- 
velopes it for transmission over its own local area 
network. 
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Bridge System for Connecting Networks 



BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates generally to interconnec- 
ting local area networks and more specifically to 
interconnecting ethernet networks using a token 
bus network backbone. 



Description of the Prior Art 

Local area computer networks (LAN) are in- 
stalled in stand alone networks known as seg- 
ments. Each segment connects all of the comput- 
ers of a specific group. The segments can each 
comprise a different company department, such as 
an accounting or engineering department. Mes- 
sages are transmitted in packets along the network. 
Each packet contains information identifying the 
source computer and the computer to which the 
message is intended. Each computer on the net- 
work typically has a filter which screens out mes- 
sages which are not intended for it. One type of 
network commonly used as a local area network is 
the ethernet network. 

Devices called bridges are used to connect 
different segments, together. If there are several 
segments, then a bridge is used to connect each 
segment to the next segment in the series. When 
the bridge receives a message packet, it looks at 
the destination code and determines if the mes- 
sage is intended for a node in that same segment. 
If it is, then the bridge can ignore it. If it is intended 
for a node not in that segment, then the bridge 
passes the message over to the next adjacent 
segment. The message is passed along from 
segment-to-bridge-to-segment until it reaches the 
proper destination segment. 

A problem with this way of connecting seg- 
ments is that the entire system becomes increas- 
ingly inefficient with each additional segment. This 
is because each message must hop from segment- 
to-segment until it reaches its destination. Thus, 
the traffic load is increased in each segment be- 
tween the source segment and the destination seg- 
ment. 

Another problem with this type of system is 
that ethernet networks cannot be used over long 
distances. A token bus network can be used to 
cross long distances. However, transmitting be- 
tween an ethernet and a token bus network has 
proved difficult due to the differences in the me- 
dium access control protocols of the networks. 



SUMMARY OF THE PRESENT INVENTION 

It is therefore an object of the present invention 
to provide a system for connecting together a large 
5 number of networks in an efficient manner. 

It is another object of the present invention to 
provide a system for connecting together networks 
across long distances. 

It is another object of the present invention to 
70 provide a system which does not change the pro- 
tocols of the networks being connected. 

It is a further object of the present invention to 
provide a system for transmitting local area net- 
work packets over a network backbone. 
75 In an exemplary embodiment of the present 

invention, the system comprises a token bus net- 
work which is used as a backbone. A number of 
ethernet networks are each connected to the back- 
bone through a bridge device known as a network 
20 interface module (NIM). 

In operation, messages from one ethernet seg- 
ment are enveloped by a NIM and sent over the 
token bus network to a NIM connected to. the 
ethernet segment to which the message is in- 
25 tended. That NIM then de-envelopes the message 
and puts it out on the destination ethernet network. 
Each NIM has a unique I.D. code and each NIM 
stores information on which NIM is associated with 
which node. In this way, the NIM can direct the 
30 enveloped messages to the required NIM. The 
other ethernet networks are not disturbed. 

It is therefore an advantage of the present 
invention in that it provides a system for connect- 
ing together a large number of networks in an 
as efficient manner. 

It is another advantage of the present invention 
in that it provides a system for connecting together 
networks across long distances. 

It is a further advantage of the present inven- 
ts tion in that it provides a system for transmitting 
local area network packets over a backbone net- 
work. 

It is another object of the present invention in 
that it provides a system which does not change 
45 the protocols of the networks being connected. 

These and other objects and advantages of the 
present invention wiil no doubt become obvious to 
those of ordinary skill in the art after having read 
the following detailed description of the preferred 
so embodiments which are illustrated in the various 
drawings figures. 
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IN THE DRAWING 

Fig. 1 is a block diagram of a bridge system 
of the prior art; 

Fig. 2 is a block diagram of the system of 
the present invention; 

Fig. 3 is a diagram of the medium access 
control headers for the ethernet and token bus 
networks; 

Fig. 4 is a diagram of the backbone network 
packet of the present invention; and 

Fig. 5 is a block diagram of the network 
interface module of the present invention. 

DETAILED DESCRIPTION OF THE PRESENT IN- 
VENTION 

Fig. 1 shows a block diagram of a network 
bridge system of the prior art and is designated by 
the general reference number 10. System 10 in- 
cludes a number of ethernet networks 12, 14, 16 
and 18. A number of nodes, 20, 22, 24. 26, 28, 30, 
32 and 34 are associated with the networks 12, 14, 
16 and 18. The networks are connected in series 
by a number of bridges 36, 38 and 40. 

The bridges 36, 38 and 40 typically contain 
memories for storing data. The stored data would 
include the addresses of nodes on the networks on 
either side of a bridge. For example, bridge 36 
would have information stored associating nodes 
20 and 22 with one side of bridge 36 and as- 
sociating nodes 24, 26, 28, 30, 32 and 34 with the 
other side of bridge 36. 

In operation, node 20 may want to transmit a 
message packet to node 22. The message packet 
contains information which identifies the source of 
the message as node 20 and the destination as 
node 22. The message would be transmitted on 
network 12 and node 22 would identify the mes- 
sage as being addressed to it. The bridge 36 would 
also receive the message. Bridge 36 would read 
the destination address and know that the message 
is intended for node 22. Bridge 36 already knows 
that node 22 is on the same side of bridge 36 as 
node 20 which originated the message, so bridge 
36 can ignore the message. 

Now, suppose node 20 wants to send a mes- 
sage to node 24. The packet is transmitted on 
network 12. Bridge 36 receives the message pack- 
et and determines that its destination is node 24. 
Bridge 36 knows that node 24 is on the other side 
of bridge 36, so" bridge 36 would transmit the 
message packet to network 14. Since all of net- 
works 12, 14. 16 and 18 are ethemets, there is no 
need for the medium access protocol of the mes- 
sage to be altered or translated and the bridge 36 
can output the message packet with no change. 



In another example, node 20 may want to send 
a message to node 32. The message packet with 
node 32 as its destination is placed on network 12. 
Bridge 36 reads the destination of the message 

5 and realizes it resides on the other side of bridge 
36, so it transmits the message to network 14. Now 
bridge 38 reads the message and realizes that the 
destination node resides on the other side of 
bridge 38, so it transmits the message to network 

io 16. Finally, bridge 40 reads the message. Bridge 
40 knows that the destination resides on the other 
side of bridge 40, so it transmits the message to 
network 18. Node 32 can then pick up the mes- 
sage. 

75 The problem with system 10 can now be ap- 

preciated. Messages between networks 12 and 18 
must be transmitted across networks 14 and 16. 
The traffic on networks 16 and 14 is correspond- 
ingly increased. As more and more networks are 

20 added to the system in series, the traffic becomes 
greater and greater and the entire system becomes 
less efficient. 

Fig. 2 shows a block diagram of one embodi- 
ment of the system of the present invention and is 

25 designated by the general reference number 50. 
System 50 comprises a plurality of ethernet net- 
works 52. 54, 56 and 58. Network 52 has a plurality 
of nodes 60 and 62. Network 54 has a plurality of 
nodes 64 and 66. Network 56 has a plurality of 

30 modes 68 and 70. Network 58 has a plurality of 
nodes 72 and 74. Each network has been illus- 
trated with two nodes, though in actuality many 
more nodes would be associated with each net- 
work. 

35 A token bus network 80 is used as a backbone 

for a system 50. A plurality of network interface 
modules (NIM)s 82. 84, 86 and 88 connect net- 
works 52. 54. 56 and 58. respectively, to network 
80. Network 50 is shown with four ethernet net- 

40 works connected to network 80, however, in opera- 
tion, many more ethernet networks could be con- 
nected. 

Fig. 3 shows a diagram of the structure of the 
packet headers in the medium access control pro- 

46 tocol layer and is designated by the general refer- 
ence number 100. An IEEE 802.3 reference net- 
work header 102 is shown. A destination field 104 
provides information on the address to which the 
packet is directed. A source field 106 provides 

so information of the party who sent the packet. A 
length field 108 defines the length of the packet. A 
data field 110 provides the high protocol layer 
information. A pad field 112 provides additional 
characters needed to achieve a minimum packet 

55 size. An FCS field 114 provides the frame check 
sequence. The FCS is a number which is cal- 
culated using an aigorithm which uses the informa- 
tion in the other fields. This number is then reca!- 



3 



5 



0 281 785 6 



culated at the destination to verify that the informa- 
tion in the packet is correct. 

In commercial applications today, the ethernet 
network is commonly used. The header packet of 
the ethernet is the same as the IEEE 802.3 header 
with one exception. The length field of the IEEE 
802.3 header has been made obsolete and the 
ethernet uses field 108 to contain information on 
the protocol type. In this way, two different protocol 
systems could work on the same ethernet network. 

An IEEE 802.4 reference header 120 is also 
shown. Token bus networks use the IEEE 802.4 
standard. A frame control field 122 identifies the 
frame type. A destination field 124 identifies the 
address to which the packet is being sent. A 
source field 126 identifies the address of the par- 
ties sending the packet. The data field 130 contains 
the higher protocol layer information. An FCS field 
132 provides the frame check sequence. The data 
field 130 is further divided into a header 140 and a 
data area 142. Header 140 is an IEEE 802.2 LLC1 
type 1 header which describes the data in data 
area 142. Data area 142 actually contains the high- 
er protocol layer information. 

It is apparent that translating between the 
ethernet header 102 and the token bus header 120 
is difficult. Some fields must be eliminated and 
others added. Due to this fact, the FCS number 
must be recalculated based on the new frame. !f an 
error was made in translating some of the data, the 
new FCS number would be calculated using the 
erroneous data. When the packet reaches the final 
destination and the FCS is checked, the error in 
translation would not be detected. 

Fig. 4 shows a diagram of the IEEE 802.4 
header as used in the present invention and is 
designated by the general reference number 150. 
The IEEE 802.4 reference is used in the token bus 
networks. The present invention avoids the prob- 
lems of translating the ethernet header by envelop- 
ing the entire ethernet header inside the 802.4 data 
field. Header 150 contains a frame control field 
152. A bridge destination field 154 designates the 
particular NIM address to which the message is 
addressed. A bridge source field 156 designates 
the NIM from which the packet originated. A field 
157 comprises the data field 130 from the token 
bus frame 120. A header field 158 contains the 
header 140 from the token bus frame 120. Field 
160 comprises the data area 142 of the token bus 
frame 120 and comprises the entire ethernet frame 
102 including an ethernet destination field 162, an 
ethernet source field 164, a protocol-type field 166, 
an ethernet data field 168, and an ethernet FCS 
field 170. An 802.4 FCS field 172 follows the data 
field 157. 

Returning now to Fig. 2, when system 50 is 
first put into operation, each NIM 82, 84, 86 and 88 



start to construct address index tables. For exam- 
ple, suppose node 60 puts out a packet on network 
50 for node 62. NIM 82 would receive the message 
and look at the ethernet source field {106 in Fig. 3). 

5 NIM 82 would then store node 6 with a number, 
zero for example, which would designate node 60 
as being in network 52. At this point, NIM 82 would 
not have an address for node 62 stored. So, NIM 
82 would envelope the ethernet header inside the 

jo token bus header as shown in Fig. 4. The bridge of 
NIM destination is unknown to NiM 82, and the 
bridge destination field 154 in Fig. 4 would have a 
multicast address to all other bridges, NIMs 84, 86 
and 88 in this case. The bridge source field 156 

75 would contain the address of NIM 82 on the back- 
bone 80. The FCS field 172 would then be cal- 
culated using the entire token bus header 150. 

NIM 84 would receive the token bus frame 
from NIM 82 over the token bus backbone network 

20 80. NIM 84 would note the bridge source field 156 
and the ethernet source field 164 of the packet. 
NIM 84 would store information associating node 
60 with NIM 82. Next, NIM 84 will de-envelope the 
ethernet frame by removing the field 160 from the 

25 token bus frame 150. The ethernet message is 
then placed on network 54. Since the ethernet 
address is for node 62, all nodes on network 54 
would disregard the message. The same procedure 
would occur in NIM 86 and 88 because they would 

30 also receive the multicast message. 

After an initial start-up period, each of NIMs 82, 
84, 86 and 88 will have stored information which 
associates every node with its particular NIM. Now 
if NIM 82 receives a message on network 52 from 

35 node 60 to node 62, NIM 82 would ignore the 
message. If node 60 sends a message for node 74, 
then NIM 82 would envelope the message and 
address it only to NIM 88. NIM 88 would de- 
envelope the packet and send it over network 58 to 

40 node 74. NIMs 84 and 86 would ignore the mes- 
sage because it is not addressed to them and 
networks 54 and 56 would not be disturbed at all. 

System 50 can handle a large number of ether- 
net networks over one token bus network. This is 

45 because each packet sent over the token bus will 
be directed only to the proper destination network. 
The other ethernet networks do not have to be 
burdened with messages which are not intended 
for them. This greatly reduces the traffic load in 

so each network and correspondingly increases the 
efficiency of each network. 

Fig. 5 shows a block diagram of a NIM and is 
designated by the general reference number 200. 
NIM 200 has a microprocessor 210 which is con- 

55 nected to a bus 212. The microprocessor 210 is an 
Intel 80186 or equivalent. A dynamic FtAM 214, an 
EPROM 216, an identification EEPROM 218, a 
BOOT PROM 220 and a non-volatile RAM 222 are 
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all connected to bus 212. An interface co-processor 
224 is connected between an ethemet network and 
bus 212. Co-processor 224 is an Intel 82586 micro- 
processor or equivalent. An interface co-processor 
226 is connected to bus 21 2. Co-processor 226 is 
a Motorola 68824 microprocessor or equivalent. A 
modem is connected between co-processor 226 
and a token bus network. 

The BOOT PROM 220 is used to run test 
programs on the NIM components when the sys- 
tem is first turned on. This is much the same as in 
personal computer BOOT PROMs. When a mes- 
sage packet arrives from the ethernet network, the 
interface co-processor 224 determines if it is a 
valid message. If it is a valid message, then the 
message is stored in the dynamic RAM 214 and 
the microprocessor 210 is interrupted. The micro- 
processor 210 uses the software in the EPROM 
216 to evaluate the message and if needed, en- 
velope the message for transmission to the inter- 
face, co-processor 226, modem 228 and on to the 
token bus network. The software in the EPROM 
216 instructs the microprocessor 210 to store the 
addresses of the various nodes in the dynamic 
RAM 214 and the non-volatile RAM 222. If the NIM 
200 experiences a power outage, then on power- 
up, the NIM 200 will still have addresses in the 
non-volatile RAM 222 and there is no need to 
relearn all of the addresses. 

The identification EEPROM 218 contains a 
code address which is unique to each particular 
NIM. On power up this bridge address is stored in 
the interface co-processor 226. When a packet is 
received from the token bus, the interface co- 
processor 226 verifies the code address. If the 
message has a bridge destination different than 
that in the identification EEPROM 218 or multicast 
address, then the message is ignored. If the bridge 
destination is the same as this particular NIM or its 
multicast address then the co-processor 226 stores 
the message in dynamic RAM 214 and interrupts 
the microprocessor 210. The microprocessor 210 
then uses software in 21 6 to de-envelope the mes- 
sage and output it on the ethemet network. The 
multicast address is also stored in the EPROM 
216.. 

. It can be seen that the system of the present 
invention utilizes the microprocessor 210 of the 
NIM 200 in an efficient manner. The microproces- 
sor is only disturbed by messages on the back- 
bone network 80 if the messages are specifically 
directed to it. The co-processor 226 filters out other 
backbone messages. Messages from the ethernet 
network must ail be evaluated by the microproces- 
sor 210. 

The preferred embodiment of the present in- 
vention has been described using ethemet net- 
works for the local area networks and using a token 



bus network for the backbone network. However, 
other types of networks could be substituted for the 
local area network and the backbone network. 

Although the present invention has been de- 

5 scribed in terms of the presently preferred embodi- 
ments, it is to be understood that such disclosure 
is not to be interpreted as limiting. Various alter- 
ations and modifications will no doubt become ap- 
parent to those skilled in the art after having read 

70 the above disclosure. Accordingly, it is intended 
that the appending claims be interpreted as cover- 
ing alt alterations and modifications as fall within 
the true spirit and scope of the invention. 

75 

Claims 

1. A network interface module (NIM) for con- 
necting a local area network to a backbone network 
20 comprising: 

a first interface co- processor connected to a 
local area network for transmitting and receiving 
local area network messages to and from said focal 
area network; 

25 a second interface co-processor connected to 

a backbone network for transmitting and receiving 
backbone network messages to and from said 
backbone network; 

a memory means connected to said first and 

30" seco/id interface co-processor for storing a bridge 
identification address, a table of addresses, and for 
temporarily storing said local area network and 
backbone network messages; and 

a logic means connected to the first and 

35 second interface co-processors and the memory 
means for storing information from a source ad- 
dress in said local area network message in said 
table of addresses, comparing a destination ad- 
dress in said, local area network with said table of 

40 addresses, and if the destination address is asso- 
ciated with the bridge identification address, then 
ignoring said local area network message, and If 
the destination address is associated with the 
bridge identification address of a second NIM, then 

46 enveloping said local area network message in a 
backbone network message addressed to said sec- 
ond NIM, and if the destination address is not 
associated with any of the addresses in said ad- 
dress table, then enveloping said local area net- 
so work message in a backbone network message 
addressed to be multicast to all other NIMs on said 
backbone network, the logic means is further used 
for storing source address information in said back- 
bone message in said table of addresses, and de- 

55 enveloping said backbone network message for 
transmission to said local area network. 
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2. The device of claim 1 wherein, 

the logic means envelopes a local area 
network message into a backbone network mes- 
sage by putting the local area network message 
into the data field of a backbone message, adding 
a destination address comprised of either a NIM 
identification address or a multicast address, and 
adding a source address comprised of said NIM 
identification address of the particular NIM. 

3. The device of claim 2 wherein, 

the logic means further envelopes a local area 
network message in a backbone network message 
by calculating a backbone frame check sequence 
and adding it after said data field of said backbone 
message. 

4. The device of claim 3 wherein, 

the logic means de-envelopes a backbone 
message by using the backbone frame check se- 
quence to verify the accuracy of said backbone 
message and if it is a valid message, then the logic 
means takes the entire data frame of the backbone 
message and passes it to the first interface co- 
processor for transmission to the local area net- 
work. 

5. The device of claim 1 wherein, 

the local area network is an ethernet network. 

6. The device of claim 1 wherein, 

the backbone network is a token bus network. 

7. The device of claim 1 wherein, 

the memory means is comprised of a dynamic 
RAM, an identification EEPROM and a non-volatile 
RAM. 

8. The device of claim 1 wherein, 

the logic means is comprised of a micropro- 
cessor and an EPROM. 

9. A method for connecting a local area net- 
work to a backbone network comprising the steps 
of: 

connecting a first interface co-processor to a 
local area network; 

connecting a second interface co-processor to 
a backbone network; 

connecting a memory means to said first and 
second interface co-processors, said . memory 
means containing a NIM identification address and 
a table of addresses; 

connecting a logic means to said first and 
second interface co-processors and said memory 
means; 

receiving a local area network message in said 
first interface co-processor and temporarily storing 
said local area network message in said memory 
means; 

using the logic means to store information 
from a source address in said local area network 
message in said table of addresses; 

using said logic means to compare a 
destination address in said local area network mes- 



sage with said table addresses, and if the destina- 
tion address is associated with the NIM identifica- 
tion address stored in said memory means, then 
ignoring said local area network message, and if 

5 the destination address is associated with the iden- 
tification address of a second NIM, then enveloping 
said local area network message in a backbone 
network message addressed to said second NIM, 
and if the destination address is not associated 

70 with any of the addresses in said address table, 
then enveloping said local area network message 
in a backbone network message addressed to be 
multicast to all other NIM on said backbone net- 
work; 

75 receiving and evaluating a backbone network 

message at said second interface co-processor and 
temporarily storing said backbone network mes- 
sage in said memory means if said backbone net- 
work message is valid; 

20 using said logic means for storing source 

address information in said backbone message in 
said table of addresses; and 

using said logic means for de-enveloping said 
backbone message for transmission to said local 

25 area network. 
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© A large number of local area networks (52, 58) 
are each connected to a backbone network (80) 
through a network interface module (NIM) (82-88). 
The NIM transmits messages from one local area 
network to another local area network across the 
backbone network by enveloping the local area net- 
work message inside the data field of a backbone 
network message. Each of the NIM constructs a 
table of addresses. The backbone network mes- 
sages are each addressed to the particular destina- 
tion- NIM. The destination NIM receives the back- 
bone network message and de-envelopes it for 
transmission over its own local area network. 
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